There is a clear trend in the communication industry suggesting over the top communication, and web based communication services are increasing their share in the overall communication market. The availability of high speed Internet in homes and offices and the widespread proliferation of smart phones is making real time communication (RTC) over Internet possible.
Most of the Internet based real-time communication services (like Skype, Viber, etc.) need a plugin or propriety client on the PC/smartphone. Google and various browser vendors are working on a framework called ‘WebRTC’ to enable real time communication using a browser without the need for a propriety client or plugin. Standardization of the WebRTC is in progress in W3C and IETF.
WebRTC based communication service offer advantages over native applications in regard to convenience, platform compatibility, security, maintenance, richness, interoperability, standardization and reuse of RTC Functions,
There is no need to install plug-in or native applications in WebRTC. WebRTC Application Programming Interfaces (APIs) shield the platform details and an application uses WebRTC APIs. A WebRTC App runs in a sandboxed environment in the browser, providing better security than when such a sandbox environment is not used. A newer version of a browser might break plugins which were designed to be compatible with an older version browser, while WebRTC APIs offer stability. Applications based on plugins lack the rich flexibility of native browser resources due to privilege restrictions. This, in turn limits the innovation possible with these applications. Plugins are proprietary, while WebRTC standardizes RTC functions and the interfaces leading to interoperable applications. Availability of RTC functions in browser will enable rapid application development with the reuse of browsers' RTC features across applications.
WebRTC is an emerging initiative to support full communications (including voice and video) natively from a web browser without the need for any additional plugins or a native Application on the client. This approach has the potential to spawn a new wave of “Over the top” players entering the market, as the barrier is now even lower. With the WebRTC approach, there is no longer a need to persuade a user to adopt a specific plugin.
Already Chrome, on android mobiles, supports WebRTC. It is anticipated, WebRTC will be used not only as a new communication service, but also to access the existing communication infrastructures like call centers from web site. So, there is a need of an interworking node, e.g., a WebRTC server node, to interwork the signaling over WebSocket to the Session Initiations Protocol (SIP) signaling used by legacy and IMS endpoints.
A WebRTC Server, which is an interworking node responsible for interworking the Application signaling over WebSocket to standard SIP signaling, needs to be highly available and scalable in order to support the real-time communication needs.
A webRTC server in the communications system, which is supporting an ongoing communications session, may fail. It would be advantageous if a replacement webRTC server could take over support for the ongoing communications session as quickly as possible, e.g., without disruption to the media communications between two endpoint user devices. Methods and apparatus that allow flexibility in terms of which webRTC servers can replace other webRTC servers in the communications system would be advantageous. It would also be advantageous if storage requirements and failover support could be achieved with little or minimal amounts of memory shared between or common to servers which may be used to support a communications session. By avoiding the use of shared or common memory to support failover in the case of a failed server, better scalability can be achieved and/or replacement or addition of a server may be possible than in the case where a common memory needs to be shared and accessible between servers supporting communications sessions.
In view of the above discussion, it should be appreciated that there is a need for improved methods and/or apparatus for supporting server failover, and/or for supporting redundancy with regard to session state that may be needed by a communications server to maintain a communications session. It would be particularly useful if at least some embodiments supported WebRTC failover without the need for a common shared and accessible memory in the communications network being used by WebRTC servers to share session state information.